perm filename TTYFTP.PRO[DLN,MRC] blob
sn#488357 filedate 1979-10-25 generic text, type T, neo UTF8
First Edition
C
SLIGHTLY MODIFIED DIALNET PROTOCOLS
for TTYFTP
Mark Crispin and Ignacio Zabala
Modified by Bill <Yeager@Sumex-aim>
on Oct 22, 1979
Dialnet - TTYFTP Protocols October 22, 1978
Conventions
All numbers without an explicit base (ie, octal or decimal)
specified should be interpreted as octal unless the number is
immediately followed by a dot, in which case it is decimal.
All three-digit octal numbers should be interpreted as
representing an 8.-bit byte, with bits right-justified within the
number (ie, from 000 to 377). Bytes are expressed in the form as
returned by the modem (ie, lsb first in the data stream).
All six-digit octal numbers should be interpreted as
representing a 16.-bit double-byte, with bits right-justified within
the number (ie, from 000000 to 177777). Double-bytes are expressed
in the form returned by the modem (ie, low order byte and lsb first);
ie, 010041 is transmitted as 041 020.
NOTE: ALL TTYFTP implimentations are as JOBs running under whatever
constraints the particular operating system wishes to impose. NO monitor
changes are required to impliment TTYFTP. This has the advantage of ease
of implimentation. But care must be take not to overrun input buffers,
since monitor defaults sizes are used(with the exception of the RT11 impli-
mentation). So, on TENEX for example, TTYFTP is limited to 119 bytes of
input buffer space, and the largest packet it will send is 54 bytes. See
window discussion below.
1
Dialnet-TTYFTP protocols October 22, 1979
Preface
you glad you use Dialnet? Don't you wish everybody
"Aren't
did?"
Dialnet/TTYFTP provides a capability for geographically separated
computers, called hosts, to communicate with each other. The host
computers typically differ from one another in type, speed, word
length, operating system, etc. Each computer utilizes Dialnet via
ordinary phone lines and special modems.
As in many other data communication schemes, a layered approach
has been selected in the design of these protocols. Each layer
sees the immediate lower layer as a "black box" and need not be
concerned about its internal structure. The lowest layer is the line
protocol of the modems, which transfers data bytes over the phone
lines and does necessary byte framing, but otherwise has no error
correction facilities. At this writing, the modem type used are
VADIC VA3405 1200/1200 baud full duplex asyncronous modems.
NOTE: TTYFTP accepts any MODEM or line interface, eg, DL11 under RT11, and
DJ11-DZ11 under RSX11M can be used in conjunction with a modem.
Next is the host-host layer, which breaks the data stream into
chunks, or packets. Each packet is checksummed and sequenced, so
that retransmission can be done on a packet whose previous
transmission was corrupted in some way. Many systems may want to
implement this layer in their operating system, so all Dialnet user
programs will behave at this level in the same manner.
Finally comes the user-level protocols. This includes file
transfer, mail, linking, telnetting, etc. These are user-level
programs, and Dialnet has been designed with enough flexibility to
allow for users to create private protocols of their own.
Questions concerning Dialnet protocols should be addressed to:
Mark Crispin
Artificial Intelligence Laboratory
Stanford, California 94305
Phone: (415) 491-4712
ARPAnet: MRC@SU-AI
TTYFTP questions should be addressed to:
Bill Yeager
SUMEX computer project
TB105
Stanford University Medical Center
Stanford, California 94305
Phone: (415) 497-5336
ARPAnet: Yeager@Sumex-aim
2
Dialnet-TTYFTP protocols October 22, 1979
It is the author's intent that these protocols are both simple
in their implementation and powerful in their operation. Certainly a
major design consideration was to design protocols that ordinary
mortals could implement on their systems.
3
Dialnet-TTYFTP protocols October 22, 1979
Host-Host Protocol
All data is sent in the form of packets, which contain a packet
header, optional data, and a packet trailer. The packet header
serves to identify the type of packet, the size of the data area and
provides information necessary for data flow and error correction.
The packet trailer provides a checksum for the packet. Packets are
framed at each end with a start of packet and an end of packet
marker.
The bytes which indicate start of packet are called SOP, and
consist of ASCII DLE (220) followed by STX (202); similarly, the
bytes which indicate end of packet are called EOP, and are ASCII DLE
followed by ETX (203).NOTE: TTYFTP uses 204 for EOP to avoid confusion
with ↑C on those systems that will NOT allow a program to trap this
character.
Note that the 200 bit is on in DLE, STX, and
ETX. If a 220 byte is to be sent, it is quoted by being sent twice.
DLE followed by anything other than STX, ETX, or DLE is currently
undefined; any such combination when received should be discarded.
020, 002, and 003 are not considered to be DLE, STX, and ETX.
NOTE: TTYFTP allows any DLE-CHR sequence, and when it is encountered
40 is subtracted from the CHR - it assumes that 40 was added to the
character prior to transmission. This enables a list of special characters
to be sent without modifying the monitor in any way. EG. ↑S, ↑Q on TOPS20,
RT11, and RSX11M. DLE DLE sequence is also allowed, and in this case 40
is NOT subtracted from the second DLE.
All packets have a packet number, which for most packets starts
at 001 and is incremented with each packet sent. The packet number
wraps around to 001 from 377. Up to two (the default window size)
PACKETS may be sent before an acknowledgement is received for (at
least) the first packet. The window begins with the first
unacknowledged packet; therefore the window size is an allocation
which is used up as packets are sent and is given back as packets are
acknowledged. TTYFTP also keeps track of the input buffer size of the
host to which it is sending, and it will NOT send a packet that REQUIRES
ACKNOWLEDGEMENT if there is no room in the input buffer. Also, if an
acknowledgement packet (NOP with non-zero packet number) must be sent
and the window is closed but there is room in the input buffer, it WILL
BE sent by TTYFTP.
Some packets (ie, NOP, NAK, and ERR) have a packet number of
000. These packets do not count against the window, and are not
remembered for retransmission after they are sent. Therefore they
are lost if an error occurs while they are being transmitted. This
is because what information they convey is generally timing-critical;
if the packet was lost nothing would be gained by sending it again.
If the sender intends to temporarily "go idle", it should send a
NOP, repeated every five seconds or so. Here TTYFTP uses a 30 second
interval to prevent overflowing input buffers. This assures the receiver
that the sender is still up, and serves to inform the receiver if any
of its pending packets were missed. However, if the sender has
packets waiting to be acknowledged, it should retransmit the last
packet on the acknowledgement pending list. This is to avoid a
possible deadlock which occurs when the last packet before the
sending goes idle is lost.
A properly received packet with a non-zero packet number must be
acknowledged for the sender to know that the receiver successfully
4
Dialnet-TTYFTP protocols October 22, 1979
received the packet and to release that packet from the window. Each
packet has an acknowledgement byte which is used for this purpose.
This byte in a packet sent by the receiver contains the number of the
highest successfully received packet. Acknowledging a packet implies
acknowledging all unacknowledged packets with lower packet numbers,
therefore a successfully received packet can merely set the
acknowledgement byte for the next packet to be sent without actually
forcing a packet to be sent.
Packets must be received in sequence, with the exception of
packets with packet number 000 (see above). If the receiver receives
a packet it has already acknowledged it should discard it. Packets
which have a sequence number higher than the expected packet and
packets with incorrect checksum should be discarded, and a NAK sent
for the expected packet. In the event of a framing error, the
receiver should discard all input until an SOP is encountered in the
input stream. If a packet is discarded for being out of sequence,
its acknowledgement byte should still be used, otherwise an
acknowledgement may be unnecessarily missed.
NOTE: TTYFTP does NOT use the acknowledge byte in this case. Out of
sequence Packets are NAKd. There is always the slight chance that the ACK
byte is in error, and the packet passed the checksum; and in this case
one might discard a packet that will then be required to be retransmitted
at a later time.
In Dialnet, the window is optional; in particular, an
implementation which uses the window should not get upset because the
foreign host disobeys it (it can of course neglect to acknowledge
packets which cause data overruns and force them to be re-sent).
However, any implementation which is trying to be reasonably
efficient should do something about handling windows and telling the
foreign host what sort of window size it can live with.
There is no official timeout for deciding whether a host is
still alive or whether the phone connection is poor enough to be
unusable. Each implementor must decide these for him/herself.
TTYFTP uses a 15 minute timeout after which the SERVER job will detach
itself or log it self out, and the USER portion types a warning message
when 60 seconds have elapsed without hearing from the host.
The packet checksum algorithm used is the result of a
conversation with Knuth. The checksum is 16. bits long and all of
the packet header variables and the entire data area. It does NOT
include the packet trailer or the SOP/EOP packet framing codes. Note
that framing checks happen before the checksum check.
The algorithm is: (all numbers should be read as octal)
checksum := 1;
while newchar do
checksum := (checksum * 013215 + newchar) & 177777;
In PDP-10 assembly code, this would be:
; CHKBYT adds a byte to the checksum in SUM.
; At the beginning of each packet SUM is
5
Dialnet-TTYFTP protocols October 22, 1979
; initialized to 1.
; Call: MOVE CHR,<byte from data stream>
; PUSHJ P,CHKBYT
; <return>
CHKBYT: IMULI SUM,013215
ADDI SUM,(CHR)
ANDI SUM,177777
POPJ P,
There is always at least one word in the data part of the
packet. The data part size refers to the number of additional words
in the data part. Hence the data part can be from 1 to 256 data
bytes long. This means that the "data size" field in the packet
header is actually one less than the actual data size.
The motivation for this is that a power of two is a convenient
unit of storage for many systems. In addition, many implementations
will find it convenient to pack four data bytes in a single storage
word. With framing and DLE doubling stripped, this means that the
packet header will be exactly one storage word, and the data part
will begin on a storage word boundary. In addition, the data part of
a maximum-size packet will also end on a storage word. This is
significant for many systems in terms of buffering; whether a byte-
by-byte copy must be done or a faster word transfer. The PDP-10
implementation at Stanford exploits this; an IBM-style machine can
derive similar benefit.
TTYFTP sends at most one BYTE of data in every packet, but does
not adhere to the "word boundary" convention. It can of course receive
packets adhering to this convention since the number of data bytes is
included in the packet header.
In the CLS, NAK, EOF, and INT op-codes the data byte is
meaningless and should be ignored, however, it still must be present.
Additionally, this byte should always be zero, to allow these op
codes to have a meaningful data part in a future revision of the
protocol.
There are no restrictions on the size or content of the data
part of a NOP packet, except the packet structure restriction that
1≤size≤256. Since, however, the data is ignored by the receiver, a
NOP packet would generally have a one-byte data part, although some
systems might want to pad to 4 data bytes (note that this means the
size field in the packet header is 3!) to keep things on word
boundaries.
6
Host-Host Protocol Dialnet Protocols September 7, 1978
Packet Format
________________________________________
| |
| 2 bytes SOP framing mark |
| |
|======================================|
| Channel # | Op Code |
| (4 bits) | (4 bits) |
|__________________*___________________|
| 3 bit Multi- | 5 bit |
|plexing chan. | Packet number |
|______________________________________|
| |
| 1 byte Acknowledgement |
|______________________________________|
| |
| 1 byte Data size |
|======================================|
| |
| 1 byte Data word |
|______________________________________|
| |
| (specified |
| by data Additional data bytes |
| size byte) |
| |
|======================================|
| |
| 2 bytes Packet checksum |
| |
|======================================|
| |
| 2 bytes EOP framing mark |
| |
|______________________________________|
7
Host-Host Protocol Dialnet Protocols September 7, 1978
Host-Host Op-Codes
In the descriptions below, certain arguments are passed along
with the commands. These arguments are listed in the order in which
they occur, along with their byte size. They all occur in the DATA
field of the packet.
000 NOP (No-op)
This op code is a no-operation and should be ignored by the
receiver except that the packet still has to be acknowledged, unless it
has a ZERO packet number, ie, sent when the 5 sec. timer expired and
no packets had been received. It is used to acknowledge a packet without
doing anything else.
001 RPC (Request Process Connection)
(optional) 8 bytes of process ID
(optional) 1 byte of initial window size
This is the establish connection op code. It serves a dual
purpose; to request establishing a connection, and to confirm
establishing a connection. In the first case, the data area contains
an 8.-byte process ID, which is a handle to the remote process the
sender wishes to connect to. In the latter case, no process ID is
specified. A single byte may follow the process ID to specify an
initial window size.
002 CLS (Close Connection)
This is the terminate connection op code. It may either
terminate an existing connection or abort a request for one.
003 WIN (set WINdow size)
1 byte of window size
This op code sets the input window size; ie, it suggests to the
receiver how many packets it may send before waiting for an
acknowledgement. The minimum (and default) window size is 2 packets.
The absolute maximum window is 127.; however, many systems may want
to set a smaller maximum window. At Stanford, the system maximum is
16. packets.
8
Host-Host Protocol Dialnet Protocols September 7, 1978
004 MSG (MeSsaGe)
0 to 256. bytes of data
This is the data transmission op code. The contents of the data
part are passed to the tertiary process.
005 NAK (Negative AcKnowledgment)
This op code requests that the receiver retransmit all
unacknowledged packets that it sent.
006 EOF (End Of File)
This op code is used to raise an "end of file" condition on a
particular channel to indicate the end of a data stream.
007 INT (Interrupt)
This op code is used to raise an "interrupt" condition on a
particular channel. It is intended that a user process be informed
of the interrupt twice; when it is received, and when it occurs in
the data stream (the latter is to indicate the end of the "interrupt"
condition).
010 ERR (Error)
0 to 256. bytes of ASCII error text
This op code is used to send a protocol error warning. It is
intended that a receiver of such a warning output the contents of the
data part of the message (which should be an ASCII string) on a
logging terminal so that the support staff can determine the cause of
the problem and take corrective action. This op code should be used
judiciously, since needless usage would only defeat its purpose.
011 RCT (receipt - TTYFTP only)
This op code is used to tell the recipient that the sender has
received a packet - the number in the acknowledge field - and do NOT
send any more packets until an acknowledgement (NOP with non-zero packet
number) is received for the packet. This allows the temporary closure
of the line, and for example, can be used when data buffers are full, or
the system load is too high to send/receive data. NOP packets with
zero packet number can be sent even if the line has been closed by a RCT.
9
Dialnet-TTYFTP protocols October 22, 1979
Connections
In the discussion below, U refers to the process which initially
provoked the connection or user, S refers to the the process
passively waiting for a connection or server.
Channel 0 is to be used for ICP.
Following the establishment of a dialup connection, U should
send a few NOP's to S to avoid possible problems with dropped bytes
while connecting.
U must know the process ID of the S it wants to connect to. As
far as Dialnet is concerned, process ID's are arbitrary ASCII
strings. However, conventions have been established as noted
elsewhere.
U sends an RPC with the process ID at S it wants to connect to.
S may have been waiting for a connection, or perhaps was created by
S's host as a result of the RPC. If S does not exist or S's host is
unable or unwilling to make the connection at the present time, S's
host should return a CLS to refuse the connection.
Otherwise, S accepts the connection by sending an RPC back to U,
with a null process ID. The connection has now been established, and
the process ID is no longer used by the host-host protocol. The two
processes may now pass data back and forth using the various Host-
Host op codes.
When a host wishes to terminate a connection, it sends a CLS.
Once a CLS has been sent, no further MSG's may be sent and any MSG
sent should be replied to with an ERR. Of course, a new connection
may be established with RPC. Breaking the phone connection implies
terminating the connection.
When a connection is terminated, the recepient of the CLS should
send a CLS to confirm terminating the process.
10
Dialnet-TTYFTP protocols October 22, 1979
Introduction to Tertiary Protocols
All protocol communication in the higher level Dialnet protocols
(e.g. MAIL, File Transfer) uses a list format for messages. Each
message therefore has the form
(<identifier> <item> ... <item>)
where the items themselves are either identifiers or have a
similar structure. The object of this scheme is to ensure
flexibility.
Suppose, for example, that one of the items in a protocol
message designates a user name. Initial designs of Dialnet may allow
only a character string without parentheses like SMITH to designate
the user. Later this might be elaborated to also allow a complex
designator like (SUCCESSOR SMITH) to designate the person who has
replaced SMITH in this job assignment.
There is no present intention that the Dialnet protocols will be
subject to rapid elaboration. The present object is merely to build
these protocols so that they will not be subject to blind alleys.
Therefore, there are no fixed size fields, and item that is initially
represented by an atomic name may later be replaced by some kind of
expression, and new terms may be adjoined to lists. Thus if an item
is presently denoted by a three term list, an elaborated protocol may
later call for a four item list, but if the same initial identifier
is used, it should still be possible for a recipient to ignore the
fourth item and still use the message.
We believe that these conventions, at slight cost in initial
implementation, will make future improvements easy should they be
required.
11
Dialnet-TTYFTP protocols October 22, 1979
File Transfer Protocol
Introduction
The File Transfer Protocol (FTP) provides Dialnet hosts with a
set of commands for transmission of files among them.
Because we count on quite different systems using Dialnet, it is
necessary to establish a small set of essential commands and replies
that are implemented by all of them in order to make possible the
communication between any two sites. On top of this, additional
commands are defined that enchance data transfer between two similar
hosts.
FTP commands consist of standard 8-bit ASCII strings. Any
number appearing in a command will always be decimal.
The interactions between the various parties in an FTP
transaction may be best described by the following diagram:
__________ __________
| | Data | |
----->|(Output)|>---------->|(Input) |>--
! | | Channel(1) | | !
! | | | | !
! | | | | !
! | | Command | | ! _______
! | Server |<==========>| User |<======>| User|
! | Process| Channel(0) | Process| ! |_____|
∧ | | | | !
________ | | | | ! __________
| File | | | Data | | --->| File |
|System|<-<|(Input) |<----------<|(Output)|<----<| System |
|______| |________| Channel(2) |________| |________|
Under request from the user process, the user program
establishes a connection with the desired server. Channel 0 is
employed for exchange of commands and replies between the user and
server programs. When a connection is established, the server sends
a "reply" consisting of a greeting message (which can contain
anything, such as system name, etc.).
At this point both sites must reach some agreement about the
characteristics of the flow of data between them so that the
transferred data is interpreted in the same way at both ends of the
connection. This is the purpose of the DATA c␈mmand. The agreement
may be renegotiated at any time in which no data transmission is in
12
Dialnet-TTYFTP protocols October 22, 1979
progress. The user may then issue service requests thru the command
channel.
Data is transferred on the data channels. When the server
receives a request to retrieve a file, it tries to obtain the file
and, if everything goes right, it sends a positive reply on channel 0
and starts sending the data on channel 1. Upon receipt of the reply,
the user will start taking packets from channel 1 and will eventually
store the data in its file system. When a store or append operations
are requested it is the user program which gets the file and sends it
to the server thru channel 2. After the request, the server is
listening to this channel and when the packets arrive, it will store
the data in its file system.
Data transmission is terminated by any of the following reasons:
- The receiver gets an end of file on that
channel. This is the normal termination for a
successful data transfer.
- An interrupt has been issued on the data
channel. Any data previously received in that
transmission is discarded.
- The command channel is closed. The command
channel may be closed by the server at any time,
but it will typically do so only after a request
from the user who will send it when finished
using the FTP service.
13
Dialnet-TTYFTP protocols October 22, 1979
FTP Replies
The following pages contain a description of the commands
available in the Dialnet File Transfer Protocol and the corresponding
set of replies.
It is strongly recommended that all the commands be implemented,
although clearly not all have the same importance.
There are only four possible replies. In each of them the first
item identifies the reply. The second item is a list which contains
a string which in most cases is passed to the user without further
processing. Hence, there is a choice as to the amount of information
to return in a reply.
The replies are:
(OK (<optional-text>))
The command has been accepted as issued and will cause
the desired effect. If the command requires two
replies, this is the primary positive reply.
(DONE (<optional-text>))
This is the secondary reply for a data transfer
command whose primary reply was positive. It
indicates that the data transfer is finished.
(BUSY (<optional-text>))
The server cannot attend the request but if you keep
trying it may eventually give you the service.
(FAILED (<optional-text>))
You are losing with this command. The argument will
tell the reason.
NOTE: Since the s-expression requires balanced right and left parenthesis,
TTYFTP will send ↑V( if a "(" appears in the optional text. One,
could of course put in the ")" to balance things, but TTYFTP knows
that ↑V(, or ↑V) is really just "(" or ")". Also, see the DIR
command below.
14
Dialnet-TTYFTP protocols October 22, 1979
Access Control Commands
The following commands specify access control identifiers. Some
sites may not require them, but if issued they should be correct.
When needed it is the responsibility of the user program to make sure
that they arrive in the correct order. Because the server has the
faculty to close the connection at any time, it may very well do so
after several unsuccessful log-in trials.
I. (USER <user-id>)
With this command the user identifies himself to the server so
that it is granted access to its file system. Some sites might
require this command to be the first command thru the connection and
may even require a complete log-in sequence with a password and/or an
account number. A new USER command may be sent at any time, in which
there is no data transmission, to change the access control and/or
accounting information. Transfer parameters are unchanged by this
command.
Replies:
(OK)
The user has successfully logged into the foreign
host. No password is required.
(OK (PASSWORD?))
The <user-id> was accepted but a correct password is
required to continue the log-in process.
(BUSY (<reason>))
(FAILED (<reason>))
II. (PASSWORD <password>)
The argument is a character string specifying the user's
password.
Replies:
(OK)
User log-in completed.
15
Dialnet-TTYFTP protocols October 22, 1979
(OK (ACCOUNT?))
The <password> was accepted but an account
specification is required to continue the log-in
process.
(FAILED (<reason>))
III. (ACCOUNT <account>)
The argument is a string identifying the user's account.
Replies:
(OK)
Even if the server has no accounting service this
reply should be sent in case a fixed sequence has
been issued by the user.
(FAILED (<reason>))
IV. (BYE)
The user sends this message before closing the connection, to
say it is going away.
Replies:
(OK)
16
Dialnet-TTYFTP protocols October 22, 1979
The DATA Command
V. (DATA <byte-size> <type> <structure>)
The systems that communicate by means of Dialnet may have
different word (byte) lengths, employ different data representations
and structure their stored data in various ways. To solve this
problem we define some standard default values of these parameters
and employ the DATA command to change them in cases in which the
standards are not adequate. All users of Dialnet must implement the
defaults, that is, they must be able to send and receive meaningful
data in contiguous logical units of 8 bits, which can be interpreted
as standard ASCII characters and are always transferred in groups
delimited by end-of-file characters.
When a connection is first established, the server will assume
that the default values will be used and will be prepared to make the
necessary data conversions from his own to the default form when
sending, and from the default to its own when receiving.
Often user and server will be similar machines and converting
the data to the standard default form will be unnecessary. The DATA
command allows a user to tell which are the parameters that he wants
the server to employ on the data in order to minimize the user's data
conversion effort. It can be issued as many times as desired but not
during a data transmission. Of course, it can also be used to return
to the standard default form.
All the arguments should be given, and precisely in the
specified order. They stand for:
<byte-size> is a decimal number specifying the desired
logical byte size, i.e., starting with the first
bit transmitted on the data channel, every <byte-
size> bits are a complete entity. The default
byte size is 8.
<type> may be:
ASCII Data consist of a sequence of
contiguous standard 8-bit ASCII
character. The end of a line of text
is denoted by a sequence <CRLF>. This
is the default type.
EBCDIC Data consist of 8-bit EBCDIC
characters. The end of a line of text
is denoted by a <NL> character.
17
Dialnet-TTYFTP protocols October 22, 1979
IMAGE Data consist of a stream of
contiguous bits that should be taken
in contiguous groups of size given by
the value of <byte-size>. This type is
intended for efficient transmission
between similar machines.
<structure> may be:
FILE File (no internal structure). The end
of a file is marked by an end-of-file
packet.
RECORD The data is grouped in records
delimited by an EOR (end of record)
marker. At the end of the file there
is an end-of-file packet after the
last EOR.
If a site receives and stores a file while certain parameter
values are active and is later requested to return that file using
the same values, the input and output copies should be identical.
Also we must require that any transformation suffered by a file
during the process of storing it do not affect the contents of that
file if output in another form.
Replies:
(OK)
Good, the server agrees.
(BUSY (<reason>))
You are not allowed to change the transfer parameters
now.
(FAILED (<reason>))
The server may not have implemented one or several of
the parameter values specified by the arguments,
or it can accept each of them in some combination
but not the three together as required in the
command or the arguments are not in the correct
order, etc.
18
Dialnet-TTYFTP protocols October 22, 1979
FTP Service Commands
VI. (RETRIEVE <for-path-name>)
This command tells the server to send the file specified by
<for-path-name> to the user. Upon receiving it, the output side of
the server's program should look for this file in the server's file
system. Then it will report the result of the lookup operation (so
that the user's program can be informed) and, if successful, will
start transmitting. At the end, a report about the result of the
transfer operation will also be emitted.
Primary replies:
(OK (<text>))
The lookup succeeded and the server has started
sending the file.
(BUSY (<reason>))
(FAILED (<reason>))
Secondary replies:
(DONE (<text>))
The transfer is finished and the data channel closed.
(STOPPED (<text>))
Channel 1 was closed before an end-of-file had
arrived. The part of the file that had already
been transmitted (if any) will not be saved, i.e.
the RETRIEVE command will not have any effect.
VII. (STORE <for-path-name>)
The server should open a file named <for-path-name> and store in
it the data that the user will send. If a file with that name already
exists at the server site it will be overwritten, otherwise the
server should create it.
Primary replies:
(OK (<text>))
19
Dialnet-TTYFTP protocols October 22, 1979
The file has been found or created. The server is
ready to receive the data thru channel 2.
(BUSY (<reason>))
(FAILED (<reason>))
Secondary replies:
(DONE (<text>))
The transfer is finished (an end-of-file has been
received). The file is closed and so is data
channel 2.
(STOPPED (<text>))
Channel 2 closed before an end-of-file arrived. The
part of the file that had already been received
(if any) will not be saved. The STORE command
will not have any effect.
VIII. (APPEND <for-path-name>)
This command tells the server to open the file specified by
<for-path-name> for input and append to it the data that the user
will send thru channel 2. If no file exists with that name this
command will have the effect of a STORE command.
Primary replies:
(OK (<text>))
The file has been found or created.
(BUSY (<reason>))
(FAILED (<reason>))
Secondary replies:
(DONE (<text>))
The transfer is finished (an end-of-file has been
received). The file is closed and so is data
channel 2.
20
Dialnet-TTYFTP protocols October 22, 1979
(STOPPED (<text>))
Channel 2 has been closed before an end-of-file has
arrived. The part of the file that had already
been received (if any) will not be saved. The
APPEND command will not have any effect.
IX. (ABORT)
This command tells the server that the file transfer requested
by the previous command has been cancelled. For that purpose an
interrupt packet is sent to the server on the data channel. Because
the server was attending that channel, it will recognize the packet,
terminate any data transmission or reception and turn its attention
to the command channel. Any data received so far will be discarded.
The previous command will have no effect on the files of either the
user or the server. Had the transfer already been completed and the
data channel closed, the receiver would have already closed the file
in its file system and no abortion would be possible.
NOTE: TTYFTP protocol is as follows:
An interrupt is sent on the channel for which the file transfer
is being aborted. The recepient then replies with an interrupt
and waits for more instructions.
The usual sequence is
INT -->
<-- INT
(ABORT) -->
<-- (OK (...whatever..))
Only file transfers can be aborted because there is no control
on the other services from the very first moment in which the
corresponding command is issued.
Replies:
(OK)
(FAILED (<reason>))
X. (RENAME <for-path-name1> TO <for-path-name2>)
NOTE: This command has NOT been implimented by TTYFTP as
of Oct. 22, 1979.
The server is instructed to change the name of <for-path-name1>
to <for-path-name2>.
Replies:
(OK)
(BUSY (<reason>))
(FAILED (<reason>))
21
Dialnet-TTYFTP protocols October 22, 1979
XI. (DELETE <for-path-name>)
The server is instructed to delete the file specified by <for-
path-name>.
Replies:
(OK)
The file has been deleted.
(BUSY (<reason>))
(FAILED (<reason>))
XI. (DIRECTORY <for-dir-name>)
This command asks the server for a list of the files in the
directory specified by <for-dir-name>. If no argument is given a list
of the files in the log-in directory should be sent. The information
will be contained in the reply (sent thru the command channel).
Replies:
(OK <file-list>)
<file-list> is the requested list of files. It should
be passed directly to the human user.
THIS IS THE ONE PLACE WHERE TTYFTP DIFFERS FROM DIALNET IN PROTOCOLS.
TTYFTP sends the file information on the DATA channel so it doesn't
have to worry about "(" or ")" appearing in the names.
The protocol is as follows for TTYFTP:
(DIRECTORY <for-dir-name>) -->
<-- (OK (here comes list))
<-- <file-list> on DATA channel 1.
<-- (DONE (list terminated)) on channel 0.
(FAILED (<reason>))
XII. (STATUS)
NOTE: TTYFTP has NOT implimented this command as of Oct. 22, 1979.
With this command the user asks for whatever information the
server may want to send him. It may be issued at any time. The
information will be sent as a reply on channel 0 (the command
channel!) and is intended exclusively for human users.
Replies:
(OK <information-list>))
The contents of the <information-list> should be
directly sent to the human user for its
interpretation. This is the only legal reply.
22
Dialnet-TTYFTP protocols October 22, 1979
Glossary
The following terms are used in this document and are defined
here to remove ambiguity:
ACKNOWLEDGEMENT -- an 8.-bit quantity which specifies
the packet sequence number of the highest
consecutive packet which has been successfully
received. An acknowledgement implies that all
packets with lower sequence numbers have been
received as well.
BYTE -- an 8.-bit quantity. While Dialnet
transmissions are to be considered as a bit
stream, this concept is convenient to use for
many reasons.
BYTE SIZE -- this refers to the byte size of data as
seen by the host computer. All Dialnet
transmissions should be considered bit stream
transmissions sent in units of 8.-bit bytes.
CHANNEL -- an 8.-bit quantity identifying which data
stream this packet belongs to. Channels have no
meaning to the host-host protocol, only to higher
level protocols. Channel 0 is the channel
normally used.
CHECKSUM -- a 16.-bit quantity containing a packet
checksum, used in error detection.
CONNECTION -- a logical connection between two
processes. Connections are bidirectional.
DATA -- an arbitrary amount of data which is either
used as arguments in the Host-Host protocol or as
data to be passed to a process utilizing Dialnet.
DATA COUNT -- a 8.-bit quantity indicating how many
bytes are in the data field of the packet after
the first data byte.
Dialnet -- a communications protocol for data
transmission over standard phone lines. This
term also refers informally to the set of hosts
which implement Dialnet.
23
Glossary Dialnet Protocols September 7, 1978
EOP -- a marker used to indicate end of packet. EOP
consists of ASCII DLE (220) followed by ETX
(202). It is a violation of packet framing for a
packet to end with anything other than an EOP. A
packet is not completely received until this code
has been received. Note that the 200 bit must be
set for an EOP to be recognized as such.
HOST -- a system with Dialnet-compatible modems and
Dialnet-support software which knows the
telephone number of at least one other host.
HOST-HOST PROTOCOL -- The protocol which provides for
compatible communication between two processes
running on (probably) dissimilar hosts.
LINE TRANSMISSION PROTOCOL -- The protocol which
provides for error free transmission between two
hosts with a common modem which use the Host-Host
protocol.
OP CODE -- a Dialnet host-host protocol operation
code.
PACKET -- a logical unit of data transmitted over a
Dialnet link. The packet is the elementary unit
of Dialnet transmissions. A packet is basically
data with a header and trailer.
PACKET FRAMING -- a technique used in the line
transmission protocol which requires that all
packets start with an SOP marker and end with an
EOP marker. A packet must be properly framed for
it to be considered to have been received
correctly. Framing errors cause the packet in
progress and all succeeding data to be discarded
until framing is restored.
PACKET NUMBER -- an 8.-bit quantity which uniquely
identifies a packet at a given point in time.
This is used to identify packets if necessary in
error recovery. Packet numbers may be recycled
after both hosts have agreed that the packet
associated with this packet number has been
correctly sent and received.
PROCESS -- an entity utilizing Dialnet. Dialnet
24
Glossary Dialnet Protocols September 7, 1978
traffic consists of communications between
processes.
PROCESS ID -- an 8.-byte ASCII string which uniquely
identifies the process. See the ICP and higher-
level protocols for process-ID conventions.
SERVER -- the initially passive process in a
connection.
SOP -- a marker used to indicate start of packet. SOP
consists of ASCII DLE (220) followed by STX
(203). It is a violation of packet framing for a
packet to begin with anything other than an SOP.
Any data received when an SOP is expected should
be discarded. Note that the 200 bit must be set
for an SOP to be recognized as such.
TIMEOUT -- A delay time for a specified action. If
the desired action does not occur within a
specified time, a "timeout" action is taken.
USER -- the initially active process in a connection.
WINDOW -- The margin for packets vs. their
acknowledgements so that acknowledgements do not
have to be completely synchronous with packets.
WINDOW SIZE -- The maximum number of unacknowledged
packets which may be pending at any time. This
is similar to what the ARPAnet calls "message
allocation".
25